-
Notifications
You must be signed in to change notification settings - Fork 13.6k
[experiment] first draft of init array syntax #143553
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #143582) made this pull request unmergeable. Please resolve the merge conflicts. |
8c3dff6
to
04fd5fd
Compare
This comment has been minimized.
This comment has been minimized.
☔ The latest upstream changes (presumably #143538) made this pull request unmergeable. Please resolve the merge conflicts. |
04fd5fd
to
c6a4400
Compare
This patch allows parsing of the syntax `init [ v1, v2, v3, .. ]` and certain level of type checking on HIR level. Signed-off-by: Xiangfei Ding <[email protected]>
c6a4400
to
2007f50
Compare
The job Click to see the possible cause of the failure (guessed by this bot)
|
☔ The latest upstream changes (presumably #144440) made this pull request unmergeable. Please resolve the merge conflicts. |
This patch allows parsing of the syntax
init [ v1, v2, v3, .. ]
and certain level of type checking on HIR level.See Draft RFC, under tracking rust-lang/lang-team#336
Dragons ahead
This is a draft PR that is very experimental and it is posted only for very early feedback and it is not immediately mergeable.
init # ...
AST fragment as a start.The reason that this deviates from the original proposal, with the additional
#
, is to help with syntax ambiguity betweeninit[0]
as indexing into a valueinit
, versusinit [ 0 ]
as in-place initialisation.However, I would propose to switch to a macro based approach to the syntax to avoid such ambiguity.
Init
. It has the same generics structure as aClosure
and it is almost type-checked in the same way asClosure
, except that its return type expectation also contains the error type, which is to be unified with those from the nested in-place initialisation.This is still not functional, because for instance I still have to fill out some tables such as
late_bound_vars
.This patch does not include any THIR or MIR building.
The final state at which I would see this patch can be merged, is to at least we can type check the following smoke test.
Areas to improve
As of July 7th, I see that I need to work these out
InitTail
is not necessary, I should just drop itThe HIR nodeI start to appreciate this choice now because the HIR visitor would be a bit harder to write if I would decide to squash it.InitKind::Array
could be squashed so that it is just a list ofInitTail
nodesInitTail
sounds terrible and I regret the choice.r? @compiler-errors